Ends-Messaging Protocol That Recovers And Has Backward Security

ABSTRACT

The presented messaging protocol uses three new public keys in a signed and encrypted message to achieve backward security and recovery in an environment where an attacker now and then obtains the security parameters in exposed, decrypted form. Backward security is understood to mean that an adversary cannot decrypt those captured encrypted messages that the user has decrypted prior the exposure. The recovery of the protocol means that the attacker at some point of time after the exposure cannot any more decrypt messages created after the exposure. The invention can be used e.g. in encrypted email communication. New to the current state of the art is that a message contains history data: a list of recently used public keys and their Diffie-Hellman counterparts. Also new is the usage of a stored and pseudorandomly changing data used together with a just computed Diffie-Hellman shared secret to provide a value that an attacker cannot produce if he does not have a proper exposed security data and the private key required to compute the Diffie-Hellman shared secret.

TECHNICAL FIELD

The invention is about encrypted communication and its protocol. Aspecific emphasis is placed on the backward security and recoveryproperties of the protocol. It is assumed that an adversary can now andthen expose all of the cryptographical security data i.e. private keysand other data stored on participants' computers. The presented methodtries to make the damages of security data exposure as small aspossible. Practical example where the protocol can be used is encryptedemail.

BACKGROUND ART

We address the problem of encrypted communication over insecure networksusing computers whose contents can occasionally be studied by anadversary. Insecurity of the network means that it must be assumed thatnot necessarily every encrypted message reaches the intended receiver.The messages may be received at different order than they were sent. Itis also expected that an adversary can now and then expose all of thecryptographical security data i.e. private keys and other data stored onparticipants' computers. The adversary then uses this exposed snapshotof security data (called shortly snapshot) to obtain as many previous orfuture plaintexts as possible. The presented method tries to make thedamages of the security data exposure as small as possible.

Practical example is encrypted email communication. Even if everymessage would reach its destination the user may process only some ofthem and those in an ad hoc order. The user should be able to enjoy thebackward security concept: An exposure of current security data shouldnot compromise previously decrypted data. Clearly also the recovery i.e.the regaining of the state where the adversary cannot decrypt messagescreated after the snapshot would be a great advantage. It must beassumed that the user has no knowledge of the attackers success.

The usage of backward security was mentioned by Ross Anderson in aninvited lecture in Fourth Annual Conference on Computer andCommunications Security. ACM, 1997. Summary appears in: Two remarks onpublic key cryptology http://www.cl.cam.ac.uk/users/rja14/, 2001. Alsothe idea of protecting future communication after the exposure isdiscussed in the paper. According to Anderson in traditional (symmetric)systems, the backward security is provided by key updating: “two or moreprincipals who share a key pass it through a one-way hash function atagreed times: K_(i)=h(K_(i−1)).” Because of the one-way function theprevious key cannot be derived from the current key.

The future keys however can de derived by the attacker. To protect them“two or more principals who share a key hash it at agreed times with themessages they have exchanged since the last key change:K_(i+1)=h(K_(i),M_(i1),M_(i2), . . . )”. Backward security is stillprovided and also protection of future messages if the attacker missesone previous message. As noted by Anderson the advent of public keycryptography and Diffie-Hellman (DH) key exchange offers a stronger formof protection: when fresh public DH keys have been exchanged thesecurity has been regained even if all the previous traffic is decryptedby the opponent. In this invention the idea that some kind ofrepresentation of previous keys affects new ones is used together withthe possibilities that the DH key exchange offers.

This recovery or freshness feature of the DH key exchange between twoparties is widely used in the handshake phase of interactive sessionprotocols. During the initial handshake the DH key exchange is performedand the shared secret is used as a security parameter for later messageexchange. The individual messages during the session are thenencrypted/decrypted on the basis of these parameters without any furtherDH exchange. If an attacker obtains the private key of one of the DHparties the whole session is exposed. This invention can also be seen asan approach to improve the security after the initial handshake. Pleasenote that the communication need not necessarily be an online one. Thepresented protocol can naturally be used even if there are days betweenmessage movements—an example being email communication. Essential isthat in the beginning the two communication parties are introduced tothemselves via the protocol initialization.

The current literature that deals with the problem of backward securityin digital signatures and in encryption uses public keys in their moretraditional meaning: one public key is distributed to many persons,which can then use it to send encrypted messages to the creator of thepublic key. The backward security methods in current literature aredeveloped for this more general case. In this invention however thepublic keys used are intended to be used only between two specific andfixed communication parties—the fixed sender and the fixed receiver. Inthis sense our keys could be called session keys between two parties. Inour method when two persons send a message to the same receiver bothsenders use different public keys of the receiver. The senders have noknowledge of the public key the other sender uses. The more general casewhere only one public key is reserved for many senders leads to morecomplex solutions. Please note that the current literature also uses theterm forward-security in the same sense we use the term backwardsecurity: a current exposure does not expose old decryptedcommunication. The first method for the general case is R. Canetti, S.Halevi, J. Katz: A Forward-Secure Public-Key Encryption Scheme.EUROCRYPT 2003, LNCS 2656, 255-271. Springer-Verlag, 2003. Their methoddoes not provide recovery. The recovery is added by Y. Dodis, M.Franklin, J. Katz, A. Miyaji, M. Yung: Intrusion-Resilient Public-KeyEncryption. Topics in Cryptology-CT-RSA 03, Lecture Notes in ComputerScience Vol. 2612, M. Joye ed, Springer-Verlag, 2003. This approach usesspecial update and refresh messages.

If the presented protocol is used in e.g. email communication each newcontact must be processed through the protocol initialization phase. Ifthe methods based on the more general usage of public keys are used thisneed not be done—however a public key must have somehow been deliveredto the sender of the first message. Our initialization requires thatboth parties send one initialization message. Our protocol providesbackward security and recovers when messages are exchanged.

In symmetric encryption setting the problem of protecting old traffic isstudied by M. Bellare, B. Yee: Forward-Security in Private-KeyCryptography. Extended abstract in Topics in Cryptology-CT-RSA 03,Lecture Notes in Computer Science Vol. 2612, M. Joye ed,Springer-Verlag, 2003. They recommend the usage of forward-securepseudorandom bit generators to be used as a central primitive. This isour approach too. Their construction is such that the generator's inputis a previous state (seed) and it generates a new state and the requiredrandom output bits. The old state is destroyed. If from the generatedoutput bits it is infeasible to derive the previous state (seed) used,then the construction protects old outputs. To this construction we addanother input: a Diffie-Hellman shared secret. This is added to providethe recovery feature. Our state is maintained in both computers andthese states are required to go through same values during thecommunication.

By pseudorandomness it is understood to mean that it is infeasible toderive the initial seed from the outputted bits or another outputted bitfrom another ones and that if the seed is unknown the outputted bits areunpredictable. One construction that can be used is based upon theGoldreich-Levin hard-core bit and Blum-Micali iteration, see O.Goldreich, L. Levin: A Hard Core Predicate for any One Way Function.Proceedings, 21st ACM STOC, 1989, 25-32. and M. Blum, S. Micali: How toGenerate Cryptographically Strong Sequences of Pseudo-random Bits. SIAMJournal of Computing, 13. no 4, 1986, 850-864. Another PRG providingsimilar properties i.e. pseudorandom bits can be used instead of thisgenerator.

Let's now look the usage of DH exchange more closely. In traditional DHkey exchange both parties send one message before the shared secret iscomputed and the actual encryption of the plaintext can be done. Toprovide optimal backward security and recovery one could do the DHexchange always before a plaintext should be encrypted. However, nowonly one third of the messages would carry information. Assume now thatthe attacker obtains one of the private keys. Then he could decrypt onecryptotext based on the obtained private key.

If the messaging would always happen in turns—every message isreplied—the DH exchange could be done so that every message carries onenew public key for immediate DH calculation to decrypt the encryptedtext in the message and one another new public key for the next messageto be received. Every private key would be destroyed after the DHcalculation. Every message would carry information and again theattacker could only read one message based on one obtained private key.

Problems will arise if a participant is allowed to send many messagesbefore receiving a new public key. The sender of many consecutivemessages must use the most recently received public key for all themessages he sends. If the attacker obtains the corresponding private keythe backward recovery will be lost, the attacker can read all messagesdecryptable by this private key even if he obtains the key just beforethe last such message is decrypted.

One development further would be to include a fixed number of new publickeys in every message; the sender would prefer to use a public key onlyonce. Suppose now that a sender will never use more messages than thisfixed number before receiving a new set of public keys. Consider now theproperties of such a system. There would be backward security andprotocol would recover when the sender has received a new set of publickeys. The presented invention will have backward security and recover atsame time like this obvious fixed case but it uses only 3 new publickeys in every message without a limit on the number of consecutivemessages sent. One of the 3 keys is used for immediate DH calculationand two other ones are delivered to the message's receiver to be used inhis next sendings.

SUMMARY OF INVENTION

The presented protocol uses public key encryption and utilizes 3 newpublic keys in every message. These keys are randomly (pseudorandomly)generated i.e. randomness is collected from some source and pseudorandomgenerator produces the private keys, then the seed is destroyed. One ofthe public keys is used for immediate DH computation—two keys arereserved for future DH computations. New to the current state of the artis that a message may contain history information: a list of recentlyused DH public keys and identifiers of their DH counterparts. Alsostored old data called state is used together with a pseudorandom bitgenrator (PRG) when generating a new state and symmetric key—a symmetrickey is produced not only by a result of DH shared secret computation,but also with the help of this old data. A block cipher uses theproduced symmetric key to encrypt or decrypt one message.

The used PRG must have following properties: the bits produced must bepseudorandom and unpredictable i.e. from the result it must beinfeasible to derive the seed or another outputted bit from anotherones, also if the seed is unknown it must be infeasible to derive theoutputted bits. We arrange things so that the initial seed x₀ will beunknown to the attacker if he either misses a state or a DH sharedsecret—the seed x₀ is set to be the xor'd value of both of them.

One PRG that can be used is described next. Now let f be a one-waypermutation and r a random binary vector, x₀ is the initial seed, b(r,x)is a function that computes the Goldreich-Levin hard-core bit from x.Due to the Blum-Micali theorem of iterating a one-way permutation andGoldreich-Levin hard-core bit the n bits b(r,x₀), b(r,f(x₀)),b(r,f(f(x₀))) . . . b(r,f^(n−1)(x₀)) are pseudorandom and unpredictableif x₀ is unknown, the random vector r need not be unknown. The randomvector r is chosen to be the DH shared secret. This PRG has the requiredproperties. In this construction the required one-way permutation can beemulated by a block cipher's encryption operation, see the detaileddescription section.

Now if the adversary wants to proceed forward but cannot produce x₀ hecannot produce the outputted bits. If the adversary wants to gobackwards and has obtained the outputted bits and the DH shared secrethe still cannot determine x₀. Neither can other outputted bits bederived from each other if some of them are revealed to the adversary.

The history information in messages is needed because it enables thestates being produced in forward proceeding order even if messages arenot decrypted in order. In such a case the history data: a list ofrecently used DH public keys and identifiers of their DH counterparts—isread and used to produce the states and keys in order. A produced key isstored together with its message number. When a message corresponding tothis number should be decrypted the key is fetched from the store andthen removed. Only the minimum amount of history information needed isincluded in a message. When a message is decrypted the history data tobe placed in the next outgoing message can be decided. The history dataalthough consisting of public keys is encrypted—this is done to preventa casual observer from doing any conclusions from it. This encryptionkey is derived from the DH shared secret without the stored state.

When encrypting we do not store the private key used to produce the DHshared secret. This implies that the sender cannot decrypt his own sentmessages but neither the adversary can decrypt outgoing messages basedon a snapshot from sender's computer.

The protocol has recovered when the last snapshot the attacker has doesnot contain the private key whose corresponding public key will be usedin the next encrypted message to be received. Consider the case wherethe persons involved encrypt and decrypt messages in turns (they decrypta message and then send a reply) and the snapshot is obtained from onecomputer. The adversary can decrypt depending on the timing of thesnapshot either 0 or 1 message until the protocol recovers. If messagesare not exchanged in turns but many messages are received before a newone is sent it may also happen that adversary can't decrypt a singlemessage. If the timing of the snapshot is better messages can bedecrypted until the sender receives new public keys.

Two of the new public keys in a message are intended for the receiver ofthe message to be used in his next sendings as DH counterparts. One ofthe keys is used only once in a DH calculation, the other one is usedmany times if no newer public keys are available. The usage of theone-time key prevents in certain situations the attacker of using anolder snapshot in order to decrypt more messages than a newer snapshotenables.

All the messages are signed using the digital signature method of theunderlying public key scheme. The private/public key pair used isselected to be the other one than the one-time one of the latest publickeys the intended receiver is known to posses. The plaintext ends with amac-value. The PRG produces the corresponding mac-key together with theencyption/decryption key. The verification of the mac ensures thatproper symmetric keys were used and the plaintext was created by thesender and was decrypted successfully. Note that the protocol relies onthe states on different computers being updated in synchronous way, thuse.g. a restored backup of the security data may destroy this dependency.

As extra countermeasure against certain kinds of attacks the two newpublic keys in a message can be encrypted together with the plaintext.Note that then an attacker cannot know a DH counterpart unless he hasdecrypted a previous message or obtained a proper snapshot. Thisprovides protection if the underlying public key scheme or itsimplementation has weaknesses. Note also that the protocol itselfwithout this encryption of public keys provides same kind of protection:a DH shared secret alone is not sufficient to produce a symmetrickey—the previous stored state is also required.

The underlying public key scheme might be a RSA one or based on ellipticcurves or some other scheme. On elliptic curves the public keygeneration can be done on tens of milliseconds even if currentlyadequate field size is used.

To decrypt more messages the attacker may want to launch a so-called manin the middle attack. This is easiest to the attacker if he succeeds inobtaining the snapshots of both communication parties' security data atthe same time. Lets assume the parties involved are Alice and Bob, theadversary being Charlie. Alice now sends a message to Bob. Charliecaptures the message and uses the snapshot of Bob's data to decrypt itand then uses Alice's snapshot to encrypt it again for Bob and only thenpasses the message to Bob. This can continue as long as the adversarywishes. Every message from Bob and from Alice can and must bedecrypted/encrypted. Another way to start this kind of attack is tomodify the security data on Alice's computer and send a message to Alicepretending it being from Bob or to create a message to Bob based on theknowledge obtained from a snapshot from Alice's computer. The man in themiddle attack can be detected if a cryptographic hash value (used as achecksum) is computed from the message. The hash value on Alice'scomputer of a message sent from Alice's computer will differ from thatof at Bob's computer if there is an active man in the middle attack. Ifthe adversary wants to stop this attack and not arouse any suspicion hehas to modify the security data on at least one of the computersinvolved. If during active man in the middle attack one of the messagesis not captured and changed by the attacker the receiver will not beable to verify its signature.

DETAILED DESCRIPTION

A message has three parts: public, history and the text part.

The public part consists of: identifier of the receiver, message number,a new public key (called refresher), identifier of the refresher'sDiffie-Hellman counterpart (called DH identifier), 2 new public keys(called one-time and repeater) and the message text part's startingposition. As an option the one-time and repeater public keys can beplaced together with the message's text and be thus encrypted.

History part: number x, a list of x number of items each consisting of apublic key and the corresponding DH identifier (this list of items iscalled history data).

Text part: the message text, optionally the one-time and the repeaterpublic keys may be placed here, a mac-value.

The message ends with a digital signature of the whole message.

New to the current state of the art is that a message contains historydata: a list of recently used public keys and their DH counterparts.Using this history data it is possible to have a state in both thesender's and the receiver's computer that goes through same values evenif some of the messages sent are never received or not decrypted. Thereader should also notify the usage of two different kinds of publickeys: a one-time one and one that is used if no newer public keys areavailable.

The public part is not encrypted, others are but with differentsymmetric keys. The history part's key is derived from the public part'sDH shared secret without the use of the so-called key generator. Thetext part's key is derived using the key generator. A block cipherperforms the encryptions/decryptions.

A security data storage (store) hosts for each messaging contact:

Sent keys collection (a public and private key, a message number thatcarried the keys)

Signature keys collection (a public key for signature verification and amessage number)

Waiting keys collection (a message number, a public key for signatureverification, a symmetric key and a mac-key)

History data items (each item consisting of a message number and a sentpublic key and the DH identifier of the corresponding public key)

Two states: one for sending and one for receiving (a state has twoblocks b₀ and b₁, their size is the size of a DH shared secret).

Also stored are:

Latest received one-time and repeater public keys and the message'snumber that carried them

Latest sent repeater key the receiver is known to posses.

This storage is in user's computer typically in encrypted form and apassword or a passphrase is needed for its use. When the protocol isused for encryption or decryption this storage must be available to theprotocol. If an attacker succeeds in obtaining the data in this storagein decrypted form he is said to have obtained an exposed snapshot(shortly snapshot) of the security data.

A key generator produces a new state, the symmetric key for encryptionor decryption and the mac-key for plaintext verification. Theencryption/decryption key and mac-key are called shortly symmetric keys.Part of the key generator's input comes from the security data storage:the state, the other part of the input is a newly computed DH sharedsecret. The key generator uses a pseudorandom bit generator (PRG) toproduce its output. We arrange so that the initial seed x₀ to the PRGwill be unknown to the attacker if he either misses a state or a DHshared secret—the seed x₀ is set to be the xor'd value of both of them.This is a new construction compared to the current state of the art.

The used PRG must have the following properties: the bits produced mustbe pseudorandom and unpredictable i.e. from the result it must beinfeasible to derive the seed or another outputted bit from anotherones, also if the seed is unknown the outputted bits must be infeasibleto derive.

We next describe one possible PRG.

Let GL(r,x) be a function computing the Goldreich-Levin hard-core bitfrom bit vectors x and r, r and x being of equal length. The GL bit isdefined to be the inner product of x and r modulo 2: (x₁r₁+x₂r₂ + . . .+x_(n)r_(n)) mod 2, where the indices are the corresponding bits of xand r.

Let Enc(key,plaintext) be an encryption operation of a block cipher.

Let blocks b₀ and b₁ be the old state, k be the number of bits in theold state and in the symmetric keys. Let dr_(i) be the i'th derivedpseudorandom bit and x a bit vector.

Key generator—derive the new state and the symmetric keys:

Produce a block unknown to the attacker if he misses b₀ or DH sharedsecret:

x=b ₀ xor DH shared secret

Run the PRG:

For i=1 to k

dr_(i)=GL(DH shared secret,x)

x=Enc(x,b₁)

End for

The produced bits dr_(i), i=1 . . . k will form the new state and thesymmetric keys. Note that the usage of the Enc-function is the usual wayto construct a one-way hash function using a block cipher: to compute aone-way hash of x compute Enc(x,p) where p is some fixed knownplaintext. In our case the fixed plaintext varies between invocations ofthis PRG but stays the same during a specific invocation. If theattacker obtains a state s_(m) and the next state s_(m+1) but misses aDH shared secret he still cannot run the PRG forward from s_(m). Fromthe produced state s_(m+1) due to the pseudo-randomness of the hard-corebits he cannot derive other produced bits (the symmetric keys) or theinitial seed x. If the b₁ would be the same during all invocations ofthis PRG (if b₁ is hard coded in the program) the attacker could withoutobtaining a snapshot perhaps try to guess the initial x (the result ofthe xor-operation). Now he has to obtain the snapshot and guess theinitial x or without a snapshot guess both initial x and b₁. Theproperties of this PRG allow the usage of the block b₁ and the DH sharedsecret in producing the outputted bits without compromising theunpredictability and pseudorandomness of the results.

Consider now sending a message. Three new public keys are generated(called one-time, repeater and refresher). These keys are randomly(pseudorandomly) generated i.e. randomness is collected from some sourceand a pseudorandom bit generator produces the keys, then the seed isdestroyed. The used PRG can be of a Blum-Micali Goldreich-Levin type ora different one—essential is that the seed is destroyed and that aprivate key cannot be determined from another one.

This message's number is set to be one greater than the latest one sent.The generated one-time and repeater public keys are placed into theirplaces in the message and the one-time private key and the repeaterprivate key are stored in the sent keys collection. The refresher key isplaced into its place in the message, however its private key is notplaced into the store.

From the store the message receiver's latest one-time and repeaterpublic keys are fetched together with the message's number that carriedthem. If the receiver's one-time key has not been used before whensending then it is used as the DH counterpart otherwise the receiver'srepeater key is used. The DH shared secret is computed with thereceiver's selected key and with the sender's refresher key. In thepublic part of the message the DH identifier is set to be the messagenumber that carried the DH counterpart and a value indicating whetherthe one-time or repeater key is used. When the shared secret has beencomputed the private key of the sender's refresher key is destroyedwithout it being stored. This will have the implication that the sendercannot decrypt messages sent from him, but neither can the adversary usea snapshot to decrypt outgoing messages. Adversary's possibilities arelimited to incoming messages.

Next from the store the history data items for the receiver are fetchedand copied into the message. A symmetric key is derived from the DHshared secret (by e.g. computing its hash value) and the history part ofthe message is encrypted with this key. The new history data to bestored is build by adding this message's number and the refresher publickey and the identifier of its DH counterpart to the top of the oldhistory data. The message text part's starting position field in themessage's public part is adjusted based on the size of the history part.

Next the key generator is used the input being: the state for sendingmessages and the just computed DH shared secret. The new generated stateis stored and the outputted symmetric mac-key is used to calculatetext's mac-value (if the option of placing the one-time and repeaterpublic keys together with the text is used then they are also includedin this mac) and a block cipher encrypts the message text part using theproduced encryption key.

The whole message is digitally signed. The private/public key pair usedin signing is selected to be the sender's latest repeater key thereceiver is known to posses. The receiver's latest repeater public keyand this message's number that is being sent are stored in the signaturekeys collection.

Consider now decrypting a message. Based on a comparison between thismessage's number and the greatest number decrypted so far we considerthree cases: 1) This message's number is one greater; 2) This message'snumber is two or more greater; 3) This message's number is less.

If cases 1 or 2 apply then a message number x is extracted from thepublic part's DH identifier. From the store's signature keys collectiona public key is fetched based on this number x. The signature at the endof the message is verified using this public key. If the signature doesnot verify the decryption is abandoned.

The private key identified from the DH identifier is fetched from thestore's sent keys collection. The DH shared secret between the fetchedkey and message's refresher public key is computed and a symmetric keyis derived from it in order to be able to decrypt the history part ofthe message.

If we are on case 1 then the state for receiving is fetched from storeand the key generator uses the state and the DH shared secret togenerate the new state and to output the symmetric keys. The outputtedsymmetric key is used by a block cipher to decrypt the message's textpart. The mac-key produced is used to calculate a mac-value of theplaintext. The calculated mac-value is checked against the value foundafter the plaintext and if found being different the decryption phase isabandoned. The new state is stored. The received new public keys(one-time and repeater) are now the latest ones and they are stored. Thelatest repeater key the sender is known to posses is now set to be therepeater key that was in the message x when x was sent (the key isfetched from the sent keys collection).

If we are on case 2 there are messages that have not been decryptedbetween the latest decrypted one and this message. The history part ofthis received message is decrypted and the key generator will be run toproduce the symmetric keys for each message between the latest decryptedone and this message. From the history data list the first not yetprocessed refresher key and its DH identifier are identified based onthe message number in the DH identifier. The list is processed each itemin turn and the key generator is run to produce the next state and thesymmetric keys. At the same time also a public key is determined thatmust be used to verify the signature of the message in question. Foreach message the generated keys and signature verification public keywill be stored in the waiting keys collection together with the messagenumber in question. This storing into the waiting keys collection willactually take place only after this message's mac-value has beenverified. When the last item in history data has been processed thecurrent message's DH shared secret and the state produced by theiteration on history data are inputted to the key generator. Theoutputted symmetric keys are used to decrypt and verify this message'stext. If the mac-value is not verified no storing is performed and thedecryption is abandoned otherwise the storing into the waiting keyscollection is performed and the last generated state is also stored. Thereceived new public keys (one-time and repeater) are now the latest onesand they are stored.

If cases 1 or 2 apply then it may happen that after the decryptionseveral items in the store can be removed. Let x be the message numberextracted from this message's public part's DH identifier. Sent keyscollection: an item with message number less than x is removed. Theone-time private key of message number x is removed if it exists in thecollection. History data: an item whose message number is less or equalto x is removed. Signature keys collection: every item whose messagenumber is less than x is removed.

If case 3 applies the store's waiting keys collection is used to providethe signature verification public key and the symmetric key for themessage text's decryption. After signature verification and the textpart's decryption and plaintext's mac value's verification theinformation relating to this message number in the waiting keyscollection is removed. Please note that neither the history part nor therefresher key is studied in this case. The message text's startingposition can be determined from the corresponding field in the publicpart of the message.

To clarify the effect of using the one-time key consider the followingsituation: Charlie obtains a snapshot of Alice's security data beforeAlice encrypts a message to Bob. The private keys of the new public keysin the Alice's message are thus not in the obtained snapshot. Now Bobresponds with many messages to Alice before decrypting a newer messagefrom Alice. Alice decrypts the replies in order the first one being themessage x. Now Charlie obtains another snapshot before Alice decryptsthe message number y in the middle of Bob's responses. Charlie has nowthe state and private key needed to decrypt Bob's message y and messagesfrom y forward. However, Charlie cannot go backwards in the state chainand thus the message x and messages before y cannot be decrypted basedon the newer snapshot. The older snapshot exists but the problem fromCharlie's viewpoint is that when Alice decrypted the first message x shedestroyed the one-time private key. Charlie cannot proceed forward fromthe older snapshot's state since a private key is missing. If therewould not be this one-time key concept the private key used to decryptmessages x-y would enable Charlie to proceed forward from the oldersnapshot. If Alice would not decrypt the messages in order the situationwould be still the same. The private key of the one-time key isdestroyed when the state is iterated forward when processing the historydata of a message.

During the initialization of the protocol both parties send to eachother a one-time public key and a repeater public key with messagenumber 0. The keys are stored into the sent keys collection with messagenumber 0. A receiver of a repeater public key stores it into thesignature key collection with message number 0. The receiver of aone-time and repeater keys stores them as the latest ones. Store'slatest sent repeater key the receiver is known to posses is set be thejust sent repeater key.

The states' initial values are determined by a DH exchange, this publickey is in the same message that delivers the first one-time and repeaterkeys. Note that the number of blocks in the state depends on therequirements of the used PRG. In the following we assume that the stateconsists of two blocks, if this is not the case the arrangements can beeasily altered according to the number of blocks used. Let c₁, c₂, c₃and c₄be fixed blocks of data, their size being the size of the state'sblock and let Enc(key,plaintext) be an encryption operation of a blockcipher. If the public key used to initialize the states is bigger thanthe other public keys then a one-way hash function is used to produceeither one block dh₁ or two blocks dh₁ and dh₂ from its DH sharedsecret. If there is one block dh₁ available then Alice's state forsending to Bob is b₀=Enc(dh₁,c₁), b₁=Enc(dh₁,c₂) which is also Bob'sstate for receiving from Alice. Bob's state for sending to Alice isb₀=Enc(dh₁,c₃), b₁=Enc(dh₁,c₄), which is also Alice's state forreceiving from Bob. If two blocks dh₁ and dh₂ are available then Alice'sstate for sending to Bob is b₀=Enc(dh₁,c₁), b_(l)=Enc(dh₂,c₂) which isalso Bob's state for receiving from Alice. Bob's state for sending toAlice is b₀=Enc(dh₁,c₃), b₁=Enc(dh₂,c₄), which is also Alice's state forreceiving from Bob.

To convince the parties that the initialization messages are not alteredthey either a) are accompanied with a certificate and signed with thepublic key the certificate certifies or b) the parties compute acryptographic checksum (hash value) of the message sent and received andensure each other that the checksum is the same at both ends—this can bedone by e.g. using voice contact.

Please note that the history part of a message varies in size whenmessages are sent and received. Although the history part is encrypted acasual observer might draw some conclusions based on its size. Toprevent this the history part may be set to have a specificpredetermined fixed size and if the actual required size exceeds thisthen a random value from some predetermined range is added to therequired size. Let x be the most recently sent message by Alice. Amessage received by Alice which uses one of the public keys in message xas DH counterpart empties the history data of Alice. The next messageAlice sends would have history data of zero size. The above-describedmethod can be used to hide e.g. this information.

Please note that the message number in the public part of the messagereveals how many messages the sender has created. If a casual observerthen sees messages he can draw some conclusions on the messagingbehaviour of the parties. To hide the starting point of the messagenumber it can be started from some number that is derived from the DHshared secret in the protocol initialization phase.

Note also that if the one-time and the repeater public keys are placedin the message's text part then an adversary has no knowledge of arefresher key's DH public counterpart unless he has succeeded indecrypting the required message or has obtained a suitable snapshot.This provides protection if the underlying public key scheme or itsimplementation has weaknesses. The protocol itself also gives same kindof protection since a solved DH shared secret is not sufficient toproduce a symmetric key—the proper stored state is also required.

The message's public part contains the starting point of the message'stext part thus revealing the size of the history part. It is possiblenot to place this starting point information in the public part and thusavoid using the technique to hide the size of the history data. Thesolution is to add this starting point information into a list item ofthe history part's list. Now every list item contains also the startingpoint of the corresponding message's text part. During encryptionoperation when a new list item is added on top of the history data thecurrent message's text part's starting point is stored into the addeditem.

If during a decryption the current message's number is seen to begreater than the latest decrypted one then the size of the currentmessage's history part can be determined by decrypting the first one ofits blocks, now the stored number—which tells how many items there arein the list—is used to compute the size of the history part.

If during a decryption the history part is used to produce symmetrickeys then this starting point found in a list item is stored into thewaiting keys collection together with the symmetric keys and thesignature verification key. When the waiting keys collection is used todecrypt a message this stored starting point tells where to start thedecryption of the text part. Using this solution there is no need to tryto hide the history part's size from a casual observer.

1. A communications protocol comprising the parts of: A chosenunderlying asymmetric public key cryptosystem that provides aDiffie-Hellman (DH) shared secret: two persons both creating one publickey and sending the created public key to the other person can compute aDH shared secret that an observer that sees the two public keys cannotcompute, in this kind of a system each public key has a correspondingprivate key, the DH shared secret can only be computed using one publickey and a private key of the other public key; The chosen asymmetricpublic key cryptosystem must also provide the possibility to sign andverify the signature of a message: the signing of a message isunderstood to mean that only a holder of a private key can create asignature attached to a message that can be verified to be correct onlyby the corresponding public key, if the message is altered the attachedsignature will not verify, a person knowing the public key but not thecorresponding private key cannot create a valid signature; a) a messageconsisting of three parts: public part, history part and text part, atmessage's end there is a signature of the whole message; public partconsists of the message's number called msg_num, this number isincremented by one at every encryption, public keys called refresher,one-time and repeater, a number called dh_id, a number indicating theposition of the first byte of the text part in the message; history partconsists a list of items, an item consisting of a public key and anumber called h_dh_id, history part also contains a number that holdsthe count of list items; the text part consists of a text and amac-value b) a storage area on both participants' computer hard disk,storing for each contact: one state for receiving state_(R) and onestate for sending state_(S), history data, private keys, public keys forsignature verification and waiting keys, also stored are latest receivedone-time and repeater public keys and the message number that carriedthem, also stored is a private key called sig_(key) which is the privatekey of the latest sent repeater public key the receiver is known toposses; each state consists of n+1 blocks b₀ . . . b_(n), each blockbeing a sequence of data bytes, the number of these bytes in a blockbeing fixed to a predetermined value which equals the number of bytes ina DH shared secret between a refresher private key and a one-time orrepeater public key, the value of n depends on the needs of the chosenmethod to produce pseudorandom bits (c); the history data consists ofitems, each item consisting of a message number and a public key and anumber called sh_dh_id; private key items consist of a message number,private key and one bit telling whether the private key is a one-time ora repeater key; public key for signature verification items consist of amessage number and a public key; waiting key items consist of a messagenumber, a public key and symmetric keys for mac-calculation anddecryption; c) a method to produce pseudorandom bits PRG(x,b₁, . . . ,b_(n),dh,k), the input consisting of a block-sized data x, blocks b₁, .. . , b_(n) of a state, a DH shared secret dh, and number k; its outputconsisting of k bits; the outputted k bits having the property of beingpseudorandom and unpredictable if x is unknown and the blocks b₁ . . .b_(n) of a state and the dh are not unknown, the first block b₀ of astate is not inputted to the PRG, the inputted block-sized data x iscomputed at step (d); d) a method to produce a new state and symmetricencryption/decryption keys KEY_GEN(dh,b₀, . . . , b_(n),k); its inputconsisting of a DH shared secret dh, a state b₀, . . . , b_(n) andnumber of outputted bits k, the outputted k bits produced according to:x=b₀ xor dh, where xor is bitwise exclusive or operation PRG(x,b₁, . . ., b_(n),dh,k) e) encryption operation consisting of e1) generating 3 newpublic keys called refresher, one-time and repeater; these 3 new keysare generated using some either software or hardware based method toproduce pseudorandom bits: this generation produces first thepseudorandom bits that form the private keys and from the private keysare the public keys produced using the public key formulation rules ofthe chosen asymmetric public key cryptosystem; e2) computing a DH sharedsecret dh between the refresher private key and the message receiver'slatest one-time or repeater public key, the one-time key being thepreferred one but used only once; e3) the message's dh_id is set to besuch that it contains the msg_num of the message receiver's latestdecrypted message and a bit indicating whether the computed DH sharedsecret dh at step (e2) was computed against a one-time or a repeaterkey, one possible implementation is: dh_id=receiver's latest decryptedmessage's number<<1| bit, where << is left shift operation, | is bitwiseor and bit is 1 bit telling whether the one-time or the repeater key wasused; e4) fetching from computer hard disk the stored history data tothe history part of the message: an item in the history part of themessage is set to contain the public key of the fetched item and settingh_dh_id=sh_dh_id; and storing to the hard disk the history data addingon top to it a new item consisting of the message number msg_num and thepublic refresher key and setting sh_dh_id=dh_id; e5) deriving asymmetric key dh_k from the DH shared secret dh computed at step (e2)and encrypting the history part of the message with this key dh_k; e6)fetching from the storage area states and inputting at step (e2)computed DH shared secret dh and the fetched states b₀ . . . b_(n) tothe KEY_GEN(dh, b₀ . . . b_(n),k) of part (d) and producing k outputbits forming a new states for sending and symmetric keys for the messagetext's mac-value computation and encryption; e7) computing the mac-valueof the text part and encrypting the text part and the mac-value; e8)digitally signing the message using a private key sig_(key); e9) storingon the storage area the new states and storing the private keys of theone-time and repeater key together with the message number msg_num butnot storing the private key of the refresher key; e10) storing themessage receiver's latest repeater public key together with msg_num ofthis just encrypted message to the storage area for public keys forsignature verification; f) decryption operation consisting of steps: f1)if the received message's msg_num number is greater than the greatestmsg_num of previously decrypted messages then the message's publicpart's dh_id number is used and from the computer's hard disk storage ofpublic keys for signature verification a public key is fetched using themessage number in the dh_id; the signature at the end of the message isverified using the fetched public key, if the signature does not verifythe decryption is abandoned else the dh_id number is used again to fetcha private key from the storage; a DH shared secret dh_(a) between thefetched private key and the message's refresher public key is computed,a symmetric key dh_k is derived from the DH shared secret dh_(a); f11)if the received message's msg_num is exactly one greater than thegreatest msg_num of previously decrypted messages then the receivedmessage's history part is not decrypted else the message's history partis decrypted using the derived key dh_k; f12) the state_(R) forreceiving is fetched from the storage and the following computing isperformed: cur = this message's msg_num; max=greatest previouslydecrypted msg_num ; num=number of list items in current message'shistory part, these are indexed 0, ...,num−1; ind=num−(cur−max)+1;this_num=max; for i=ind to num−1   this_num=this_num+1;   fetch from thestorage area of public keys for   signature verification a public keypbk using   the message number in list item_(i)‘s h_dh_id;   fetch fromthe storage the private key using   list item_(i) ‘s h_dh_id;   computethe DH shared secret dh_(i) between   the fetched private key and thepublic key in   item_(i;)   run KEY_GEN( dh_(i),b₀ ... b_(n),k) toproduce   new values for b₀ ... b_(n) and to produce   symmetric keysfor mac-calculation and   decryption;   store in the main memory of thecomputer   (not on the hard disk storage) the fetched   public key pbkand the produced symmetric   keys so that they can be found usingmessage   number this_num; end for

run KEY_GEN(dh_(a),b₀ . . . b_(n),k) to produce new values for b₀ . . .b_(n) and to produce symmetric keys for mac-calculation and decryption;decrypt the message's text part using the produced decryption symmetrickey and calculate and verify the mac-value using the produced symmetricmac-key; if the mac value does not verify then abandon decryption elsesave to the hard disk storage the state_(R)=b₀ . . . b_(n) and save alsoto the hard disk storage area for waiting keys the produced values ofsignature verification public keys and symmetric keys that are stored inthe main memory during the “for . . . end for” iteration at step (f12),this saving is done so that these values can be fetched based on themessage number in each item; the received new public keys (one-time andrepeater) are now set to be the latest ones and are stored on thestorage area; let z be the message number in the received message'sdh_id, fetch from the storage area for private keys an item whosemessage number is z and that is a repeater key, set sig_(key)=thefetched private key, store sig_(key); from the hard disk storage area ofhistory data, private keys and public keys for signature verificationselected items are deleted based on the value of dh_id in the receivedand just decrypted message using the rule: let z be the message numberin the dh_id, from the history data items whose message number is lessthan or equal to z are removed, private key items whose message numberis less than z are removed and the one-time private key whose messagenumber is z is removed if it still exists in the storage, from thepublic keys for signature verification items whose message number isless than z are removed; f2) if the received message's message numbermsg_num is less than the greatest decrypted message number and thereceived message's msg_num can be found in the hard disk storage'swaiting keys area then from the hard disk storage's waiting keys areafetch an item whose message number is msg_num; verify message'ssignature using fetched item's public key, decrypt message's text usingfetched item's decryption key, and verify text's mac-value using fetcheditem's mac-key; if the mac does not verify abandon processing elsedelete the found item from the hard disk storage's waiting keys area; g)initializing the communication between the participants: let thecommunicating parties be Alice and Bob, let Enc(key,plaintext) be anencryption operation of a block cipher, let const₁,const₂,const₃,const₄be fixed blocks of data known both to Alice and Bob, their values neednot be secret, let's assume that the chosen method to producepseudorandom bits (c) needs as its input block-sized data x, one blockfrom a state b₁ and a DH shared secret and number k, being thus of theform PRG(x,b₁,dh,k), this implies that a state must consist of twoblocks of data: b₀ and b₁, if the PRG needs more input blocks from astate then the arrangements can be easily altered according to thenumber of blocks needed; g1) an initialization file is a file containinginitialization, one-time and repeater public keys; g2) Bob creates andsends an initialization file fb to Alice containing the initialization,one-time and repeater public keys, these keys are pseudorandomly createdas in encryption operation step (e1), Bob stores all the correspondingprivate keys; g3) Alice creates and sends an initialization file fa toBob containing her initialization, one-time and repeater public keys,these keys are pseudorandomly created as in encryption operation step(e1), Alice stores all the corresponding private keys; g4) Alice and Bobcompute a cryptographic hash value of fb∥fa using a one-way hashflmction, where || is a concatenation operation; g5) Alice and Bobcontact each other e.g. using voice communication and verify that theyboth have the same hash value of fb∥fa; g6) Alice and Bob compute a DHshared secret dh_(init) between each other's initialization public keys;Alice sets the state for sending states to be b₀=Enc(dh_(init),const₁),b₁=Enc(dh_(init),const₂); Bob sets this value to be the state_(R); Alicesets the state for receiving state_(R) to be b₀=Enc(dh_(init),const₃),b₁=Enc(dh_(init),cons₄); Bob sets this value to be the state_(S); Aliceand Bob perform the following operations: the latest decrypted messagenumber is set to be 0; the received one-time and repeater public keysare set to be the latest ones and are stored on the storage area; thereceived repeater public key is stored on the storage area of publickeys for signature verification with message number 0; sig_(key)=theprivate key of the sent repeater public key, the sig_(key) is stored;the initialization public and private keys are deleted.
 2. A method asdefined in claim 1, where the initialization file defined at step (g1)contains also a certificate ce and a signature of the wholeinitialization file file_(sig), the certificate ce consisting of astring id_string, a public key pbk_(ca), public key pbk_(sender) andsig_(ca); the string id_string containg a name of a person, the publickey pbk_(Ca) being on the possession of Alice and Bob before theinitialization at step(g) takes place, the pbk_(sender) being a publickey whose private key is in the possession of the sender of aninitialization file fb or fa, the signature sig_(Ca) being a signatureover the certificate ce and created by the owner of the private key ofthe pbk_(Ca), the signature file_(sig) being a signature over the wholeinitialization file and being created by the owner of the private key ofpbk_(sender); the steps (g2), (g3), (g4) and (g5) being replaced by thisstep: Bob creates an initialization file fb containing theinitialization, one-time and repeater public keys, these keys arepseudorandomly created as in encryption operation step (e1), Bob storesall the corresponding private keys, the certificate containing Bob'sname and public key pbk_(Bob) is included in the initialization file,the initialization file is signed by the private key of pbk_(Bob); Alicecreates and sends an initialization file fa to Bob containing herinitialization, one-time and repeater public keys, these keys arepseudorandomly created as in encryption operation step (e1), Alicestores all the corresponding private keys, the certificate containingAlice's name and public key pbk_(Alice) is included in theinitialization file, the initialization file is signed by the privatekey of pbk_(Alice); the receiver of an initialization file verifies thecorrectness of the signature sig_(Ca) using the public key pbk_(Ca) andreads the string id_string and verifies the correctness of the signaturefile_(sig) using the public key pbk_(sender), where pbk_(sender) iseither pbk_(Alice) or pbk_(Bob).
 3. A method as defined in claims 1 or2, where the method to produce pseudorandom bits (c) PRG(x,b₁, . . . ,b_(n),d_(h),k), produces the k outputted bits according to:  n=1 thusthe call form being PRG(x,b₁,dh,k);  let Enc(key,plaintext) be anencryption operation of a block cipher and GL(r,x) be a function toextract the Goldreich- Levin hard-core bit from block x using a randomblock r, dr_(i) being one produced bit, the k outputted bits producedaccording to: For i=1 to k  dr_(i) = GL(dh,x)  x = Enc(x,b₁) End For.


4. A method as defined in claims 1 or 2 or 3, where i) the size of thehistory part in a message (a) is either exactly the size of the requiredsize or the size of the history part is of a predetermined fixed sizeand if the actual required size exceeds this then a random value fromsome predetermined range is added to the required size to make the finalsize ii) the message number in the public part of the message (a) iseither started from the number one or is started from a number that isderived from the DH shared secret dh_(init) in the protocolinitialization part (g) iii) the one-time and repeater public keys areeither in the message's (a) public part or are in the message's textpart.
 5. A method as defined in claim 1 or 2 or 3 or 4, where i) themessage's (a) public part does not contain the starting point of thetext part and the message's (a) history part's list item consists of apublic key and a number h_dh_id and a starting point of a text part ii)during encryption operation (e) when a new item is added on top of thehistory data (e4) then the item consists of a public refresher key and anumber sh_dh_id and the starting point of the current message's textpart iii) during decryption operation (f) if in phase (fl1) the size ofthe current message's history part is determined by decrypting the firstblock of the history part and then using the number telling the count oflist items in the history part to compute the size of the history partiv) during decryption operation (f) if in phase (fl2) in the “for . . .end for” iteration when the history part is used to produce thesymmetric keys for messages between the latest decrypted one and thecurrent one then the starting point of the text part obtained from alist item is stored together with the symmetric keys and the signatureverification public key v) during decryption operation (f) if in phase(f2) then the stored starting point of the text part is used todetermine the current message's text part's starting point.